COMMENT ⊗   VALID 00011 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	RLL description - for Expert System Book [Section 2.2.8.xxx]
C00008 00003	2.2.8.1. Motivation
C00010 00004			NEEDS WORK!!
C00016 00005	The next two subsections will indicate how RLL's flexibility aided us
C00018 00006	2.2.8.3. Approach to Oil Spill Problem
C00028 00007	Step 3: Decide how to represent the facts/procedures/rules...
C00043 00008	Step 4: Run the system, and modify what has to be modified.
C00048 00009	2.2.8.4. RLL's Strengths and Weaknesses
C00055 00010	2.2.8.5. Conclusion
C00059 00011		BIBLIOGRAPHY
C00062 ENDMK
C⊗;
RLL description - for Expert System Book [Section 2.2.8.xxx]

I. Motivation
  A. Why represent ESBps?
  B. How does RLL do this?
	RLL is ES in programming

II. Overview of RLL
  A. RLL has
    i. collection of pre-fabricated parts
	These can be assembled arbitrarily
    ii. tools for building new parts
  B. "Competence model" of domain of programming
	Different from other systems; and recursive

III. Our approach to solving this problem
  A. Definition of problem
	Unusual - see earlier chapter
  B. What to represent
  C. What inferences to perform, and what control structure?
    i. Agenda mechanism - why?
    ii. What is primitive and what calculated? Store values as deduced
  D. How to represent the data/procedures
	Show a unit for data, specialization, and rule, task, agenda, ...

IV. RLL's big win: Changability
  A. Simplest - in same structure,
    i. rule => task
    ii. new slots now primitive, and other computed.
  B. Currently rules pre-assigned to task.  What if had to be gathered?
	Really easy - just fix....
  C. How about resource limitations?  No problem 
	Really pertanent here, as originally did each task to completion;
	but changed, so now suspended it as needed.
  D. New type of task, whose rules are IfThenElse, or which is simply a procedure
	(rather than mishmash of rules) [This too done.]

V. Plusses and Minus
  Wins:
	On CORLL
	On LISP
	Cognitive Economy
  Losses:
  A. Immaturity - 
    i. Lacked corpus of eventual KBs about diverse control structures, ...
    ii. Untested at this time, and incomplete in terms of what it had
	Eg had never before encountered a Solvable Problem!
  B. No user front end
  C. Paradoxically, too much freedom  
	Means this took time, and did not necesaarily yield any better
	(front end could limit this)

VI.  Remaining issues
  A. Where does RLL sit?
	RLL must start with something -- its (MODIFIABLE) ESB programming nucleus, RL-1
	Actually part of EURISKO system (historically)
	  (Knew about Agenda, ... from that.)at was
  B. Long term plans
	RLL Community
	Relation to MRS
	Straddling line with rls/ESs
  C. Conclusion
	RLL basically a rl - conclusion: a full scale problem solver in really
	needed when dealing with representation issues -- this need has
	been ignored in other rls, as they are less than general,
	simplified versions.

Bibliography

2.2.8.1. Motivation

Expert systems are based on the observation that many problems 
(such as medical diagnosis, or legal reasoning) are very
difficult.  Due to both the sheer number of the constinuent
parts (eg court cases, or known laboratory techniques),
and to the intricacies of their interactions,
computers seem better able to cope with such tasks than humans.
So expert systems evolved, to help (human) domain expert manage 
both the bulk and complexities associated with these chores.

Experience with such expert systems has lead to an interesting,
although usually overlooked, insight:
the programs which help design and implement 
expert systems are themselves complex beasts.
Indeed, the domain of programming exhibits
the same types of complexities 
that prompted computer scientists to build expert systems in the first place.
For example, one can use partial specification equally well
in any planning task, whether the domain be
designing molecular genetics experiments or constructing computer programs.

		NEEDS WORK!!
2.2.8.2. Overview of RLL

This realization triggered RLL's development.
It is, first, a collection of tools which help
the KE to construct, use, and adapt an Expert System program.
In addition, it is itself a bona-fide expert system --
knowledgable in facts about programming in general, and its own subroutines
in particular.
This competency permits RLL to "understand" its internal inference procedures,
and provides the user with a tool for modifying these programs
to meet his specifications (rather than vice versa).

<<<< Begin >>>>	****** Is this needed ****** <<<< Begin >>>>
Every ES must have a "competence model" of its domain.
It is this knowledge which allows
that system to reason about the facts of its field.
(For exmple, MYCIN's "knowledge" of the facts about meningitus
is used to answer questions about the nature, cause
and effects of this disease.)
On the other hand, although MYCIN uses a backward chaining
inference engine to perform its deductions,
its "knowledge" of this process is limited to a weak "performance model"
-- MYCIN could not tell the user why it chose this particular control structure,
or indicate how exactly it works,
except by example.

While the domain of any Expert System Building program (ESBp) is
programming, few have a real "competence model" of this domain --
i.e. few have any "deep understanding" of the
programming constructs of the target programs they are building.
(EG while AGE can construct a Blackboard based reasoning system,
it cannot reason about such a system -- to answer questions about,
for example, its effeciencies; nor can it modify that BB model, to
handle, for example, a different type of rule.)

Like the other ESBps, the RLL system begins with a store of such constructs.
This class includes a non-trivial collection of types of slots, control
mechanisms, and inheritance schemes.
Each of these units is described in RLL's formalisms.
This specification is sufficiently "deep" that arbitrary ensembles
of these parts can be combined;
and it is this collection of parts which
forms the user's particular representation language.

However RLL was designed with the realization
that no single set of starting primitives could possibly satisfy
all of the users all of the time.
Hence RLL goes on to provide a number of tools,
which the user can use in constructing his own pieces --
for example, the user can create a new type of slot or inheritance procedure
by performing a simple modification to a "close" existing one.

<<<< omit this
RLL's competence model is essential at this point.
Many indirect ramifications may arise when
such a modification is performed, and the overall system must
be able to find all parts of the systems which may be affected by this change,
and update these pieces appropriately.
RLL's collection of facts about the field of programming 
may be necessary ...
omit this >>>>
<<<< End >>>>	****** Is this needed ****** <<<< End >>>>

This permits it to "understand" what it is doing as it constructs the
target Expert System, using a reasoning process not unlike Tierasias's;
only more elaborate and encompassing.  (Ie Tierasias had only a rudimentary
understanding of certain forms, within a small set of molds.
RLL can actually create new molds as necessary.)
RLL can create new modes of inference, with the same types of steps
a program like CASNET would use to incorporate a new
fact about a patient, or a new type of disease.

The next two subsections will indicate how RLL's flexibility aided us
in designing, building and updating the Oil Spill System we built, OSS.
Section 2.2.8.3 outlines the approach we followed in contructing OSS.
Notice that RLL allowed the specifics of the problem to guide the
nature and implementation of the final system
-- rather than force OSS into some particular formalism,
we designers were given great latitude in determining what
control structures to use, as well as the form of the data.
This permitted the system builders to make 
effectively all of the important design decisions,
rather than be limited by the particular options which happened
to be included in the ESBp.

One of RLL's forte is its adaptability -- this carries over to the
programs it is used to construct.
Section 2.2.8.4, in listing RLL's major points, shows how easy
it was to modify OSS, both as we were building it,
and as we revised/upgraded it, after its "completion".

We next show some of RLL's main weaknesses,
both those inherent to this type of system, and those which
are only present in the current implementation.
The conclusion answers a few remaining question - such as RLL's historical
genesis, and how problems of efficiency are solved.
2.2.8.3. Approach to Oil Spill Problem

We outline below the approach we followed in building OSS, a program
for handling (a subset of the problems associated with) inland
chemical spills.

Step 0: Determine what problem was to be solved.  
(Note this step is unusual for KE tasks in general.
The particular task is usually fairly well defined
before the programme has even been contemplated.)  
We decided OSS would concentrate on
solving the backtrack-to-source problem; but would include
a wide range of facts pertaining to this overall inland chemical spill situation.

Step 1: Decide what data should be represented.
We encoded as units facts ranging from very general statements about spills,
down to what pipe connected to which manhole in this installation.
Note that we had NOT decided yet how to represent these facts -- ie into
what set of hierarchies, and with what properties explicitly stored --
This is delayed until Step 3, after the basic control algorithm had been proposed.
(As AA texts will show, this is a good practice, as it avoids a premature
commitment to an awkward representation.
Note further that this is only possible in a system which
permits more than one structure for the data,
and more than one mode of inteference, such as RLL.)

In addition to the standard collections of individuals (eg Pipe#34), class of
such objects (eg AnyPipe, which refers to the set of all pipes) and the features
associated with such "set theoritical" objects,
we realized we would have to represent events -- general objects
which could be gradually refined.  An example should help drive home this idea:

We may want to say general things about oil spilling into a body of water --
for example, that it causes a sheen.
We would prefer to place all such facts on one place,
eg the OilSpillingIntoWater unit, and know that every more specialized case,
eg oil spilling into the stream, will inherit such facts. (That is, that oil
will cause a sheen in the stream.)
So we would want the OilSpillingIntoStream unit to inherit everything
found in the more general OilSpillingIntoWater unit.
We could go on to describe
facts about OilFromPipe93SpillingIntoWOC,
in      turn,       can       be       further       restricted       into
MachineOilFromPipe93SpillingIntoWOCAfterOutFall93,    (which    can     be
restricted  to   DayOldMachineOil#2FromPipe93'sFirstOutletSpillingIntoWOC-
AfterOutFall93onAug23.
Of course,
these  units  are  not  simply  produced
arbitrarily -- only  when you  have something to say about  such an
event will you create a gestalt  to hold this information.  If the  fact
is general,  it should  go on  a  general event  unit, which  enables  its
descendants to inherit these facts.

Anyway, the mechanism for handling this type of inheritance is distinct from
the more standard ElementOf or SubsetOf relations; and in RLL one can state
just what is expected of this relation precisely and explicitly.

Step 2: Decide on the Control/Inference Algorithms
To properly perform this step it is essential to analyze the characteristics
of the eventual system.
For example, the complete OSS is expected to perform a variety of different tasks 
-- from determining the type of the spill to performing various
<remediation tasks>, such as notifying the authorities.
Another important characteristic of this job is the timeliness and ordering
of these tasks --
the importance of recording the name of first witness dwindles when
compared with telling him not to breathe the toxic fumes.
Hence determining the toxicity of the vapors
should be of tantamont importance,
especially when the leak might be near people.

A well structured agenda seemed ideally suited to these specifications.
(An additional plus was that
even this still immature RLL system already had this program construct.)

The agenda contains an ordered list of tasks, which are processed sequentially.
Each task is designed to performs a particular bitesize job.
For example, the goal of one task may be to determine the values
of some parameters, (e.g. the task MatType attempted to deduce
the type of material which had spilt,)
another may add other tasks to this agenda,
(for example, the task in charge of effecting the Countermeasures added
several new tasks to the agenda - one to notify the authorities, another to ...)
and a third type would print out instructions/requests to the user
(eg "go to Manhole #34 and tell me if you see oil").
Other kinds of tasks (which were not necessary for this particular domain)
could create a new concept,
or decide to rearrange the tasks on the current agenda,
in recognition of some new fact.

Executing a task meant collecting relevant rules, then ordering and firing
this list in sequence.
There are many types of rules, each charged with (attempting to) achieve a
different type of goal.
(In this sense they are similar to tasks, only in a smaller scale.)
Some rules employ a known technique (algorithm) to evaluate
the value of some attribute.
(For example, determining the toxicity of a given material by looking
it up in a table.)
Others may decide to add additional rules to this rule-set,
or propose adding a particular new task to the agenda.
Still others may suggest that the current task (in which this rules occurs)
be suspended, to await necessary new data.
(Note the flow of command is quite structured.
Each rule, task or agenda* can only effect its immediate surroundings.
More global changes are performing to sending messages to its overlord,
proposing this alteration.)

* Footnote: RLL (EURISKO) is capable of dealing with several agendae --
swapping among them as need arises.
This facility was one of many RLL features which were not needed
for this job.

We will discuss below how the rules themselves will be represented,
along with the benefits of this format.

Step 3: Decide how to represent the facts/procedures/rules...

3a) Once the overall inference mechanism has been determined
3b) Decide how to represent the control mechanism
Before we can describe the sort of decisions which are made at this
point, a brief digression is necessary -- to explain RLL's basic philosophy,
and how this permits us to decide on the representation to use.
(We'll tell you when the digression is over.)

RLL is based on the "To every thing, a unit" philosophy.
This uniform representation system extends beyond just encoding the
domain knowledge -- here facts about types of oil and connectivity of pipes.
Units are used to store facts (as well as the executable code) associated
with the representation itself -- such as the descriptions for each type of
slot, or the procedure used to process a given task.

*--------*--------*--------*--------*
   M6-3
     Isa:	(AnyManhole)
     FeedsInto:	(M6-2)

   M6-2
     Isa:	(AnyManhole)
     FeedsFrom:	(M6-3)

   AnyManhole
     Examples:		(M6-2, M6-3, ...)
     Description:	This represents the class of all manholes.
*--------*--------*--------*--------*

RLL is (unfortunately) committed to using a semantic net based representation,
based on gesalts called "units",
whose attributes are defined with a set of property-value pairs*)
[* footnote: these properties are called Slots, for historical reasons.]
Within this minor constraint, RLL does provide great flexibility.
We show below that the information relevant to each type of slot is stored in
a unit.
The unit below shows that:
The value of x:FeedsInto must be a list of manholes, the only x for  which
x:FeedsInto is defined  is a manhole,  and that if  x:FeedsInto = y,  then
y:FeedsFrom = x (i.e. FeedsInto:Inverse = FeedsFrom).

*--------*--------*--------*--------*
   FeedsInto
     Isa:		(AnySlot)
     Description:	This slot maps from manholes to manholes.
     Inverse:		FeedsFrom
     HighLevelDefn:	(Composition OtherEnd ConnectedPipes)
     Domain:		Unit representing a manhole.
     Format:		SingleElements
     Datatype:		Unit repesenting a manhole.
     ToCompute:		(λ (u)  [Find the pipe, P, to which this manhole connects.
				 See which pipe, p', to which this P is connected.
				 Return the manhole m, which is connected to 
				 pipe p'.]

Note - the ToCompute of a slot indicates how to deduce its value --  i.e.
S:ToCompute is a function, F,  whose value, (F u),  is the value to  fill
u:S.
*--------*--------*--------*--------*

It is important to realize that those facts shown above are not JUST a description
of the FeedsInto type of slot -- it really is used to define this slot.
If any of those slots were ever changed, the way this slot behaves would
be affected.  For example, declaring FeedsInto:Format is a SetOfElements would
cause RLL to redefine each FeedsInto:ToCompute to return a singleton list
rather than a single atom (corresponding to that manhole,)
and to (retroactively) fix up each value of u:FeedsInto.
[If that value was empty, it would remain empty. Otherwise the single value
v would be changed into the list (v).]

Similarly, each data structure -- each rule, task, and agenda --
is stored as a unit.  
This permits (facilitates) the data to dynamically altered during
the course of the computation, or through user input.
(IE one can use the same procedures to add in a new rule that are used
to add a new pipe, or new type of slot.)

Even the procedures of this system 
-- the parts of the control structure outlined above --
are encoded in units.
As with parts of the repesentation, these facts are actually used as the
system is run.
For brevity, we will only address one of these chunks -- the rules.

Each rule has a number of obvious attributes.
First, the rule has to store the actual code which is to be executed.  
The user is spared the task of enterring the
actual LISP expression to be run;
instead he provides a higher level specification of what this rule
is to do, and RLL "expands" this definition into that code.
There are several major advantages to
providing both high and low forms of a rule specification.
In addition to facilitating the creation of a new rules,
this higher level makes the nature of the rule easier to understand
and reason about, for both the user and RLL itself.

*--------*--------*--------*--------*
   Rule#332
     Isa:		(AnyRule)
     Description:	Tell the user to hold his breath if the chemical is toxic.
     IfPotentallyRelevant:	(APPLY Toxic Chemical)
     IfTrulyRelevant:	(APPLY NearbyUser ChemicalHasSeepedTo)
     ThenTellUser:	"Do not breath this chemical!!"
     ThenAddToAgenda:	EmergencyProcedures
     Priority:		High
     OnTask:		ImminentDanger

   ImminentDanger
     Description: This task tries to find if the current situation is
	  		 dangerous; and if so, suggest solutions/fixes/alternatives.
     Isa:	  (AnyTask)
     RuleList:	  (Rule#332, ...)

   EmergencyProcedures
     Description: This task is called iff the current situation is dangerous;
			and issues many quick-and-dirty orders.
     Isa:	  (AnyTask)
     RuleList:	  (Rule#981, ...)

-Note the rule above is what the user would type, 
and not the actual running code which RLL would compute as needed.
*--------*--------*--------*--------*

Notice the code for this rule is scattered about, stored in several distinct
slots.  
This permits different parts to be executed independently --
for example, allowing the quick IfPotentially check to run to all of wide
class of rules; and then running the more expensive IfTrulyRelevant part
only on that small subset which passed.
The THEN parts are also split up.  Once the IF-parts have all passed, each
of those is, in sequence run.

Of course what we described above was the way the rule was evaluator, "by default"
- read that, unless the user has something else in mind.
Recall any user can readily modify that rule-evaluating procedure as well.
So, for example, the user may decide instead to execute the code implied by
the IfWorkingOnTask slot of a rule, or IfTodayIs, or any other set of slots.
(rather than the current IfPotentiallyRelevant and IfTrulyRelevant slots
now used.)  Or he may decide to compose a single IF-Part, which ANDs together
all of these, and runs these at once.  Similarly he may want the THEN parts
executed in a different order; or may have decided to only run those THEN parts
for which he has sufficient resources.

Note that this could not be done if each rule was simply a single piece
of compiled code.
We claimed above that it was easy to change the rule interpreter.
This is because that block of code is itself an RLL unit.
Like the rules, it is decomposed into nice sized chunks, which can
be independently modified.
One such hook is a list of slotnames which constitute
the IF part of a rule, together with a description of when that code should
be executed.  Details of this, and other specifications, can be found in [Greiner].

Before leaving this rule description, there are several other
"declarative" facts stored in each rule.
One important slot is the average CPU time this rule has spent, for executing
its IF parts and THEN parts, respectively.  This can be used for various
meta-reasoning tasks -- such as deciding whether to even consider this rule
in the future (ie did its bang justify its bucks).
Another field is the rule's author - be in human or another rule.
This can help decide who to credit/blame for good/bad rules; and this data
can help the overall system to improve its performance by relying more and more
on capable (that is, successful) rule writers.
Finally, the user himself can store any other type of information he wants --
these are just things which we feel may be useful types of statistics.

Similar mechanisms exist for processing agendae, or tasks, or other control
regimes. (For example a black board architecture, for other types of tasks.)
There are corresponding varieties of data structures - ways of extending tasks,
for instance.

Of course various inference schemes - most importantly an inheritance hierarchy -
is used to simplify data entry.  A new rule structure can be entered by
copying the existing prototype, and changing those entries which are inappropriate.
Most properties are simply inherited from more general ideas -- here from
RLL's facts about rules in general.  (In fact, for pedagogic reasons, we might
not even tell the novice user about RLL's extendability; or at least not until
he begins to complain about how awkward it is to encode this or that fact.
Until that time, he need never know anything more that a "behaviour description"
of the rule interpreter -- which is all he would ever know about the corresponding
evaluator in most other ESs.)

*-*-*-* Back to the plot *-*-*-*
The above description of rules, etc., was only to illustrate the type of decisions
one can make at this level. Here one can determine what sorts of executable slots 
a rule can have, and what such slots "mean" -- that is, when that code should
be executed.  
This is a further specification of the underlying type of algorithm 
(here an Ordered Agenda Execution,) and is done as a seperate step, after
the overall idea had been determined.

Step 4: Run the system, and modify what has to be modified.

While (4a) "Test the neo-natal system" is standard to ESBps, 
(4b) "Change those parts which should be changed" is not.
In RLL, all of the executable code is made explicit, and the user
is permitted to modify it to suit his design.
We saw in Step 3 some of tools RLL provides for such adaptations --
a high level specification language, and appropriate chunking of the knowledge.
There it was used for construction of parts -- but it can also be exploited
for retro-actively modifying existing parts.

As we saw, RLL's structure makes
changing the code as easy as altering any domain data
-- as the "program" used to test a rule's pre-condition is in the same format
as data about Oil#31, or any other bit of data used.

There are many levels of modifications permitted to data stored in RLL.
The simplest type of alteration pertains to domain data -- deciding that
Pipe#406 really joined Pipe#317, rather than Pipe#316 as you had thought.
This sort of fix could be performed in any ES.

But now suppose you realized that pipes could really join many pipes, rather
than just one.  This would be difficult to say in many languages --
indeed the only solution in most might require throwing away that Connected
link and defining a totally new ConnectedS link.  Even then all of the existing
data would have to be transfered, regrettably by hand.
Not so in RLL.  As the example given above shows, this could be done automatically.

The actual control mechanism could be altered as well.  In the initial simple
OSS system we simply pre-assigned a set of rules to each task.
Another approach would be to require each task to first gather those rules
it might need, and then fire those.  This required changing the basic task
processor, by simply putting in that "initialization" proceudure.
(Fortunately this was simply adding in a pre-existing known routine.)
Nonetheless, this fix was quite easy to make.

The initial implementation wasn't worried about time or space problems.
Each task ran until it thought it was done, and then the task which was
next in importance started up.  We then decided this was sub-optimal -- as
some tasks might become gradually less important, to where some sub-part of
another task would be more relevant.
So we changed the task-interpreter again, to suspend tasks after some length
of time.  Another fix could (but wasn't made) in the Agenda-processor to
only consider tasks which could be achieved in x units of time.
(This too would be easy - by adjusting the weight function, used to evaluator
the worth of each task.  The ordering of the agenda is determined by this measure.)

There were several other things which we considered but decided not to change:
One was to use more general types of rules -- where each rule could dictate
how to fire it, in each given situation -- eg when gathering rules, or testing
preconditions, or ....  This would permit IfThenElse types of rules,
or even "rules" which were simply a procedure 
-- perhaps a call to a Fortran program.

2.2.8.4. RLL's Strengths and Weaknesses

WINS
Throughout this report we have pushed RLL's strengths -- basically these
all derive from RLL's "competence model" of programming in general,
and of the data structures and algorithms it uses in particular.
Not mentioned was its capability to ignore InterLisp's 256K storage
maximum, using a demand paging algorithm [CORLL], and its basic Lisp support --
providing advantages like spelling correction, and inline editors.

From the above descriptions imply that RLL is actually "executing" high level
specifications of various control algorithms.
Were this true, RLL would have sacraficed any hope for speed and
(time-)efficiency for the sake of flexibility.
That is NOT the case.  While RLL does preserve these high level descriptions
definitions, it ALSO stores what these forms "compile" into -- and it
is that latter body of code which is actually run.
Much of RLL boot-strapping code is devoted to preserving such interrelationships --
so that any change to a high level form marks the (formerly-)corresponding
executable code as invalid.  On demand (that is, the next time that code
is needed,) RLL will expand that new high level definition into runnable
code; and store these low level forms so they will accessed speedily
next time the code is needed.

Returning now to the question of efficiency, we see that RLL's code
can be arbitrarily fast.  
Rather than "interpret" the high level descriptions, RLL first "compiles"
these into efficient forms, and runs this faster code.
This costs only a constant overhead -- for the one time charge of 
expanding that terse description.  From there on the code can be
arbitrarily efficient.
Basically RLL has paid for its flexibility in terms of space -- to maintain
the different versions of the code -- and not in time.
More details on how these multiple versions are maintained, used and cached
can be found in [CogEco].

LOSSES
RLL's biggest problem, at this stage of its development, is its immaturity.
By design, it will continuously incorporate new facts about control structures,
forms of representation and modes of inheritance.
However, OSS was built way too early in this ongoing design process.
For example, RLL had never encountered a Solvable Problem before --
all of its previous work had been directed towards AM-like searches --
things which never terminal with a final verdict (ie RLL knew about tasks
like "Find examples of primes", but not about things like "What is the source
of the spill").

Another big weakness, which also stemmed from its youth, was its lack of
a user front end.  A trivial example involves the way we were forced to
enter the code -- everything was in a LISPy (GetValue 'Material
'Name), rather than a nicer "Material's name".
At a deeper level, RLL did not yet have any notion of context --
this forced us designers to explicitly type (continuing the above example)
"Material name" rather than the (sufficient) "name".

A good front end could have aided in the design of this system, by suggesting
appropriate data structures and algorithms as we went.  This too was missing.

The final major fault seems almost paradoxical:
it was RLL's total adaptability.
Too much freedom, we found, forced us to spend considerable time
deciding which really was the best.
This time, of course, was not ill-spent; the final OSS is certainly
better than any comparable system which forced out hand at each step,
molding out final code to match its limited set of components.
However, any such external constaints would have
narrowed down our search, and helped us finish the system in the
four days we were allotted.
Once again this type of problem could have been alleviated in a more
mature system, which included a competent front end which would have
served as "gentle guide" during this building process.
2.2.8.5. Conclusion

We will conclude win a perspective of RLL -- in terms of its past, its
current status, and our long term plans.

A year ago, RLL began as a two week project to build a representation language on
which the EURISKO system would be built.
We soon realized many non-trivial research issues had to be addressed before
such a general, "self-encoding" language could be constructed.
(We eventually abandoned the quest for this ultimate language, satisfying
ourselves with the generality which was possible within a limited set of
constraints.  The more theoritical aspects of this rll work was taken up
by other members of the HPP community; and their next step is described in
[MRS].)

The current system plays a necessary boot-strapping role -- certain parts
of the system must be present, as these are used to fill in other parts.
(For example, the code which is used to expand high level definitions must
be present -- or at least enough of it to generate the rest of it.)
The initial control mechanism was the one needed for the EURISKO work --
which was an Agenda structure.  OSS used a minor variant of this system.

In the long run we will actually build RLL into the MRS system -- viewing
each of the seperate decomposable parts of this systems as an MRS module,
which can be individually or collectively plugged in (ie activated).
Using MRS as a Lingua Franca, RLL will be able to absorb a large corpus
of knowledge and examples from a multitude of users -- the MRS community.
Each of these other modules will hold facts about a particular domain, or
part of that domain -- eg Medical tutoring, VLSI design, or planning experiments
in the field of Genetics.
For its part,
These RLL-based MRS modules will store facts about certain types of representations,
together with their major applications.
Important in this list will be expertise about expertise.  
It is this knowledge which will enable RLL to fashion new ESs with greater
efficient and accuracy.

BOTTOM LINE
While other ESBp systems have proven expedient for tackling particular problems
in particular domains, we feel such systems will always be limited
in the scope of problems they can solve.  
We feel this problem is intrinsic to such programs, at least until
they, like the human programmers they are trying to emulate,
are capable of a crude understanding the code they are composing at something
more than the superficial level now attains.
RLL was written with the goal of attaining this necessary
undertanding.
	BIBLIOGRAPHY

[Greiner80] - "RLL-1: ..."
[Greiner & Lenat80a] - AAAI
[Greiner & Lenat80b] - Details of RLL
[Lenat, Hayes-Roth, & Waterman] - Cognitive Economy
[Smith] CORLL
[Genesereth, Greiner & Smith] - MRS

maybe an AA book  (algorithm before data structure)
CHI, FOL, LISP...